home *** CD-ROM | disk | FTP | other *** search
-
- GETSOCKOPT(2) UNIX Programmer's Manual GETSOCKOPT(2)
-
- NNAAMMEE
- ggeettssoocckkoopptt, sseettssoocckkoopptt - get and set options on sockets
-
- SSYYNNOOPPSSIISS
- ##iinncclluuddee <<ssyyss//ttyyppeess..hh>>
- ##iinncclluuddee <<ssyyss//ssoocckkeett..hh>>
-
- _i_n_t
- ggeettssoocckkoopptt(_i_n_t _s, _i_n_t _l_e_v_e_l, _i_n_t _o_p_t_n_a_m_e, _v_o_i_d _*_o_p_t_v_a_l, _i_n_t _*_o_p_t_l_e_n)
-
- _i_n_t
- sseettssoocckkoopptt(_i_n_t _s, _i_n_t _l_e_v_e_l, _i_n_t _o_p_t_n_a_m_e, _c_o_n_s_t _v_o_i_d _*_o_p_t_v_a_l, _i_n_t _o_p_t_l_e_n)
-
- DDEESSCCRRIIPPTTIIOONN
- GGeettssoocckkoopptt() and sseettssoocckkoopptt() manipulate the _o_p_t_i_o_n_s associated with a
- socket. Options may exist at multiple protocol levels; they are always
- present at the uppermost ``socket'' level.
-
- When manipulating socket options the level at which the option resides
- and the name of the option must be specified. To manipulate options at
- the socket level, _l_e_v_e_l is specified as SOL_SOCKET. To manipulate options
- at any other level the protocol number of the appropriate protocol con-
- trolling the option is supplied. For example, to indicate that an option
- is to be interpreted by the TCP protocol, _l_e_v_e_l should be set to the pro-
- tocol number of TCP; see getprotoent(3).
-
- The parameters _o_p_t_v_a_l and _o_p_t_l_e_n are used to access option values for
- sseettssoocckkoopptt(). For ggeettssoocckkoopptt() they identify a buffer in which the value
- for the requested option(s) are to be returned. For ggeettssoocckkoopptt(), _o_p_t_l_e_n
- is a value-result parameter, initially containing the size of the buffer
- pointed to by _o_p_t_v_a_l, and modified on return to indicate the actual size
- of the value returned. If no option value is to be supplied or returned,
- _o_p_t_v_a_l may be NULL.
-
- _O_p_t_n_a_m_e and any specified options are passed uninterpreted to the appro-
- priate protocol module for interpretation. The include file
- <_s_y_s_/_s_o_c_k_e_t_._h> contains definitions for socket level options, described
- below. Options at other protocol levels vary in format and name; consult
- the appropriate entries in section 4 of the manual.
-
- Most socket-level options utilize an _i_n_t parameter for _o_p_t_v_a_l. For
- sseettssoocckkoopptt(), the parameter should be non-zero to enable a boolean op-
- tion, or zero if the option is to be disabled. SO_LINGER uses a _s_t_r_u_c_t
- _l_i_n_g_e_r parameter, defined in <_s_y_s_/_s_o_c_k_e_t_._h>, which specifies the desired
- state of the option and the linger interval (see below). SO_SNDTIMEO and
- SO_RCVTIMEO use a _s_t_r_u_c_t _t_i_m_e_v_a_l parameter, defined in <_s_y_s_/_t_i_m_e_._h>.
-
- The following options are recognized at the socket level. Except as not-
- ed, each may be examined with ggeettssoocckkoopptt() and set with sseettssoocckkoopptt().
-
- SO_DEBUG enables recording of debugging information
- SO_REUSEADDR enables local address reuse
- SO_REUSEPORT enables duplicate address and port bindings
- SO_KEEPALIVE enables keep connections alive
- SO_DONTROUTE enables routing bypass for outgoing messages
- SO_LINGER linger on close if data present
- SO_BROADCAST enables permission to transmit broadcast messages
- SO_OOBINLINE enables reception of out-of-band data in band
- SO_SNDBUF set buffer size for output
- SO_RCVBUF set buffer size for input
-
-
- SO_SNDLOWAT set minimum count for output
- SO_RCVLOWAT set minimum count for input
- SO_SNDTIMEO set timeout value for output
- SO_RCVTIMEO set timeout value for input
- SO_TYPE get the type of the socket (get only)
- SO_ERROR get and clear error on the socket (get only)
-
- SO_DEBUG enables debugging in the underlying protocol modules.
- SO_REUSEADDR indicates that the rules used in validating addresses sup-
- plied in a bind(2) call should allow reuse of local addresses.
- SO_REUSEPORT allows completely duplicate bindings by multiple processes
- if they all set SO_REUSEPORT before binding the port. This option per-
- mits multiple instances of a program to each receive UDP/IP multicast or
- broadcast datagrams destined for the bound port. SO_KEEPALIVE enables
- the periodic transmission of messages on a connected socket. Should the
- connected party fail to respond to these messages, the connection is con-
- sidered broken and processes using the socket are notified via a SIGPIPE
- signal when attempting to send data. SO_DONTROUTE indicates that outgo-
- ing messages should bypass the standard routing facilities. Instead,
- messages are directed to the appropriate network interface according to
- the network portion of the destination address.
-
- SO_LINGER controls the action taken when unsent messages are queued on
- socket and a close(2) is performed. If the socket promises reliable de-
- livery of data and SO_LINGER is set, the system will block the process on
- the close attempt until it is able to transmit the data or until it de-
- cides it is unable to deliver the information (a timeout period, termed
- the linger interval, is specified in the sseettssoocckkoopptt() call when SO_LINGER
- is requested). If SO_LINGER is disabled and a close is issued, the sys-
- tem will process the close in a manner that allows the process to contin-
- ue as quickly as possible.
-
- The option SO_BROADCAST requests permission to send broadcast datagrams
- on the socket. Broadcast was a privileged operation in earlier versions
- of the system. With protocols that support out-of-band data, the
- SO_OOBINLINE option requests that out-of-band data be placed in the nor-
- mal data input queue as received; it will then be accessible with recv or
- read calls without the MSG_OOB flag. Some protocols always behave as if
- this option is set. SO_SNDBUF and SO_RCVBUF are options to adjust the
- normal buffer sizes allocated for output and input buffers, respectively.
- The buffer size may be increased for high-volume connections, or may be
- decreased to limit the possible backlog of incoming data. The system
- places an absolute limit on these values.
-
- SO_SNDLOWAT is an option to set the minimum count for output operations.
- Most output operations process all of the data supplied by the call, de-
- livering data to the protocol for transmission and blocking as necessary
- for flow control. Nonblocking output operations will process as much da-
- ta as permitted subject to flow control without blocking, but will pro-
- cess no data if flow control does not allow the smaller of the low water
- mark value or the entire request to be processed. A select(2) operation
- testing the ability to write to a socket will return true only if the low
- water mark amount could be processed. The default value for SO_SNDLOWAT
- is set to a convenient size for network efficiency, often 1024.
- SO_RCVLOWAT is an option to set the minimum count for input operations.
- In general, receive calls will block until any (non-zero) amount of data
- is received, then return with the smaller of the amount available or the
- amount requested. The default value for SO_RCVLOWAT is 1. If
- SO_RCVLOWAT is set to a larger value, blocking receive calls normally
- wait until they have received the smaller of the low water mark value or
- the requested amount. Receive calls may still return less than the low
- water mark if an error occurs, a signal is caught, or the type of data
- next in the receive queue is different than that returned.
-
- SO_SNDTIMEO is an option to set a timeout value for output operations.
- It accepts a _s_t_r_u_c_t _t_i_m_e_v_a_l parameter with the number of seconds and mi-
- croseconds used to limit waits for output operations to complete. If a
- send operation has blocked for this much time, it returns with a partial
- count or with the error EWOULDBLOCK if no data were sent. In the current
- implementation, this timer is restarted each time additional data are de-
- livered to the protocol, implying that the limit applies to output por-
- tions ranging in size from the low water mark to the high water mark for
- output. SO_RCVTIMEO is an option to set a timeout value for input opera-
- tions. It accepts a _s_t_r_u_c_t _t_i_m_e_v_a_l parameter with the number of seconds
- and microseconds used to limit waits for input operations to complete.
- In the current implementation, this timer is restarted each time addi-
- tional data are received by the protocol, and thus the limit is in effect
- an inactivity timer. If a receive operation has been blocked for this
- much time without receiving additional data, it returns with a short
- count or with the error EWOULDBLOCK if no data were received.
-
- Finally, SO_TYPE and SO_ERROR are options used only with ggeettssoocckkoopptt().
- SO_TYPE returns the type of the socket, such as SOCK_STREAM; it is useful
- for servers that inherit sockets on startup. SO_ERROR returns any pend-
- ing error on the socket and clears the error status. It may be used to
- check for asynchronous errors on connected datagram sockets or for other
- asynchronous errors.
-
- RREETTUURRNN VVAALLUUEESS
- A 0 is returned if the call succeeds, -1 if it fails.
-
- EERRRROORRSS
- The call succeeds unless:
-
- [EBADF] The argument _s is not a valid descriptor.
-
- [ENOTSOCK] The argument _s is a file, not a socket.
-
- [ENOPROTOOPT]
- The option is unknown at the level indicated.
-
- [EFAULT] The address pointed to by _o_p_t_v_a_l is not in a valid part of
- the process address space. For ggeettssoocckkoopptt(), this error
- may also be returned if _o_p_t_l_e_n is not in a valid part of
- the process address space.
-
- SSEEEE AALLSSOO
- ioctl(2), socket(2), getprotoent(3) protocols(5)
-
- BBUUGGSS
- Several of the socket options should be handled at lower levels of the
- system.
-
- HHIISSTTOORRYY
- The ggeettssoocckkoopptt() system call appeared in 4.2BSD.
-
- 4.3-Reno Berkeley Distribution April 19, 1994 3
-